Problem

server.getConfig blocks on external editor discovery, which probes ~20 editor commands sequentially, each walking every PATH entry against every PATHEXT variant. On hosts with long PATHs this exceeds the 5s EDITOR_DISCOVERY_TIMEOUT on every call, so discovery is interrupted, callers get an empty editor list, and the next call starts over from scratch. Every client connection pays the full 5s on its first RPC.

Fixes #4210. Also addresses the empty-list symptom in #4697.

Fix

Two changes in ExternalLauncher:

1. Probe concurrently. Effect.forEach(..., { concurrency: EDITORS.length }) instead of a sequential loop. Wall time becomes the slowest single probe rather than the sum.
2. Run discovery in a detached fiber and let callers join it. Effect.cached around Effect.forkDetach, so callers share one scan via Fiber.join.

The second point is deliberate. Caching the scan directly is unsafe here: Effect.cached is cachedWithTTL(self, Duration.infinity), and cachedInvalidateWithTTL memoizes the exit through onExit(self, ...) — including an interrupted exit — and with an infinite TTL never recomputes. A caller hitting the 5s timeout mid-scan would pin that interrupted exit for the life of the process. Caching the fork instead memoizes a fiber handle, which is produced instantly and cannot carry an interrupted exit; a caller that times out cancels only its own wait while the scan runs to completion in the background. On a #4210-class machine (15-99s scans) editors now resolve on a subsequent getConfig instead of never.

EDITOR_DISCOVERY_TIMEOUT in ws.ts is untouched and still bounds the cold call.

Results are unchanged. Effect.forEach preserves input order, and per-editor command preference (resolveAvailableCommand) is untouched, so the returned list is identical to what the sequential loop produced — same editors, same order. There are no per-editor timeouts, so a slow-but-present editor cannot be dropped from the result.

Relation to #4739

#4739 targeted the same issue and was closed unmerged. This takes a different approach: it adds caching rather than only bounding latency, and it avoids per-editor timeouts, which is what changed selection behaviour there. Happy to close this if you would rather solve it another way — the measurements below may still be useful for whatever lands.

Measurements

Windows 11, 46-entry PATH, 12-entry PATHEXT, desktop nightly 0.0.32-nightly.20260730.958 (patched bundle):

Discovery now completes, so clients receive a real editor list instead of a permanently empty one.

Tests

vp test run src/process/externalLauncher.test.ts — 6 passed. Two added:

• discovery is cached per service instance
• discovery survives a caller giving up: a first caller is interrupted mid-scan, and a later call must still resolve. Fails on the pre-fix commit with All fibers interrupted without error.

Not covered

This does not address the Android store app disconnect (#4901); that reproduces with a fast getConfig too and is protocol skew on the client build. This only removes the server-side stall.

Diagnosed and implemented with Claude Code (Fable 5).